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CHARGEBACK CALCULATOR 

CROSS-REFERENCE TO CO-PENDING APPLICATIONS 
5 The present application claims priority to and is related to co-pending U.S. 

Provisional Application serial No. 60/196,440, filed April 11, 2000, the contents of 
which are incorporated herein by reference. 

BACKGROUND OF THE INVENTION 

10 Field of the Invention 

The present invention is generally directed to reimbursing a first party for 
goods or services sold by a second party. One exemplary use of the present invention 
relates to a method, system and computer program product for reconciling chargeback 
amounts in a business-to-business collaborative environment (e.g., in a prescription 

1 5 drug distribution system). 

Discussion of the Background 

Chargebacks are a standard operating practice in the pharmaceutical industry. 

Chargeback payments are used by pharmaceutical manufacturers to reimburse 
20 wholesalers for products sold under a manufacturer's discounted price contract. The 

chargeback payment amount represents the difference between a Net Wholesale Price 

(NWP) and the discounted contract price negotiated between the manufacturer and 

Group Purchasing Organizations (GPO). 

Institutions managed under the GPO corporate entity buy products directly 
25 from a wholesaler under a GPO contract for which they are an eligible member. This 

transaction initiates the chargeback from the wholesaler to the manufacturer. To 

summarize the overall process flow, the wholesaler buys product from the 
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manufacturer at NWP, sells it to an institution under specific GPO contract pricing 
terms, and then "charges back" the difference to manufacturer. The difference is 
netted out with a credit to the wholesalers. 

Chargeback payment requests from the wholesalers can be processed without 

5 any errors/discrepancies. However, due to the nature and volatility of the contract and 
the demand for accuracy in the chargeback transaction, transaction errors do occur. 
Errors result when the wholesaler information regarding the transaction does not 
match the manufacturer's information. Mismatching information could include 
contract numbers, institution (DEA/HIN) identifiers, membership eligibility, product 

10 (NDC), price, etc. When this happens, the manufacturer rejects the chargeback 
request and a reconciliation process with the wholesaler is begun to resolve the 
discrepancy. While the majority of chargeback requests are processed without errors, 
there is still a significant volume of transactions (over 60,000 per month) that are 
rejected and must go through the reconciliation process. The vast majority of 

1 5 chargeback rejections/disputes occur because of membership issues. 

The current process flow for chargeback processing inside of 
GlaxoSraithKline, the assignee of the present application, typically k crudes the 
following major steps: 

(1) Wholesalers submit their chargeback request to via Electronic Data 
20 Exchange (EDI); 

(2) Glaxo SmithKline receives the initial chargeback request, validates the 
content of the chargeback transaction, and either (i) accepts the transaction for credit, 
or (ii) rejects the transaction, thereby initiating the reconciliation process; 
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(3) As the first step in the reconciliation process, GlaxoSmithKline returns the 
rejected chargeback detail line items to the wholesalers via EDI or paper in the form 
of a Chargeback Credit Memo Reconciliation Report; 

(4) The wholesaler evaluates the rejected items and can elect to (i) accept the 
5 rejection, (ii) resubmit as is, or (iii) correct and resubmit; 

(5) Resubmission of the chargeback request is accomplished only via paper; 

(6) GlaxoSmithKline processes the paper-based resubmitted chargeback 
requests; and 

(7) GlaxoSmithKline returns the reconciled chargeback request to the 

1 0 wholesalers via EDI or paper (Chargeback Credit Memo Reconciliation Report). 

SUMMARY OF THE PRESENT INVENTION 
It is an object of the present invention to address chargeback discrepancies, 
such as those that pose an industry-wide problem in the pharmaceutical industry. 

15 This object and other advantages are addressed by a contract administration 

and membership component that helps to facilitate the communications of 
membership changes between a Contract Operations group of a manufacturer, the 
Wholesalers, the institutions, and the GPO's. One of the major benefits in facilitating 
the communication of membership changes is to speed up the process of getting the 

20 correct membership recorded within the wholesalers' and manufacturer's systems. 
This results in fewer chargeback rejections. 

BRIEF DESCRIPTION OF THE DRAWINGS 
A more complete appreciation of the invention and many of the attendant 
25 advantages thereof will become readily apparent with reference to the following 
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detailed description, particularly when considered in conjunction with the 
accompanying drawings, in which: 

Figure 1 A is a schematic illustration of a computer for providing the services 
of the present invention; 
5 Figure IB is a schematic illustration of one embodiment of the computer of 

Figure 1 A providing the services of the present invention; 

Figure 2 is a data diagram of the major functions performed by and the data 
used by the present invention; 

Figure 3 A is a data flow diagram of how information is distributed according 
10 to one embodiment of the present invention; 

Figure 3B is a more detailed data flow diagram of how information is 
distributed according to one embodiment of the present invention; 

Figure 4 is a diagram showing where various features of the present invention 
are carried out; 

15 Figure 5 A is an illustrative screenshot showing a first embodiment of how a 

wholesaler can request information about chargebacks; 

Figure 5B is an illustrative screenshot showing how a debit memo search may 
be performed according to one embodiment of the present invention: 

Figure 6 is an illustrative screenshot showing the results of the request of 
20 Figure 5B; 

Figure 7 is an illustrative screenshot showing the details of the disputed items 
corresponding to the request of Figure 5B and allowing the modification thereof; 

Figure 8 is an illustrative screenshot showing a second embodiment of how a 
wholesaler can request information about chargebacks; 
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Figure 9 is an illustrative screenshot showing a scorecard selected using the 
interface of Figure 8; and 

Figure 10 is an illustrative screenshot showing a global update tool. 

5 DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Referring now to the drawings, in which like reference numerals designate 
identical or corresponding parts throughout the several views, Figure 1 is a schematic 
illustration of a computer system for managing chargebacks using a wide area 
network (e.g., the Internet). A computer 100 implements the method of the present 

10 invention, wherein the computer housing 102 houses a motherboard 104 which 

contains a CPU 106, memory 108 (e.g., DRAM, ROM, EPROM, EEPROM, SRAM, 
SDRAM, and Flash RAM), and other optional special purpose logic devices (e.g., 
ASICs) or configurable logic devices (e.g., GAL and reprogrammable FPGA). The 
computer 100 also includes plural input devices, (e.g., a keyboard 122 and mouse 

15 124), and a display card 1 10 for controlling monitor 120. In addition, the computer 
system 100 further includes a floppy disk drive 114; other removable media devices 
(e.g., compact disc 119, tape, and removable magneto-optical media (not shown)); 
and a hard disk 1 12, or other fixed, high density media drives, connected using an 
appropriate device bus (e.g., a SCSI bus, an Enhanced IDE bus, or a Ultra DMA bus). 

20 Also connected to the same device bus or another device bus, the computer 100 may 
additionally include a compact disc reader 1 18, a compact disc reader/writer unit (not 
shown) or a compact disc jukebox (not shown). Although compact disc 119 is shown 
in a CD caddy, the compact disc 119 can be inserted directly into CD-ROM drives 
which do not require caddies. In addition, a printer (not shown) also provides printed 

25 listings of chargebacks. 
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As stated above, the system includes at least one computer readable medium. 
Examples of computer readable media are compact discs 119, hard disks 1 12, floppy 
disks, tape, magneto-optical disks, PROMs (EPROM, EEPROM, Flash EPROM), 
DRAM, SRAM, SDRAM, etc. In the broadest sense, even the transmission lines of 
5 computer network adapters (e.g., modems, Ethernet, token ring and ATM) are 

computer readable media since code and/or data may be read from them. Stored on 
any one or on a combination of computer readable media, the present invention 
includes software for controlling both the hardware of the computer 100 and for 
enabling the computer 100 to interact with a human user. Such software may include, 

10 but is not limited to, device drivers, operating systems and user applications, such as 
development tools. Such computer readable media further includes the computer 
program product of the present invention for providing chargeback analysis. The 
computer code devices of the present invention can be any interpreted or executable 
code mechanism, including but not limited to scripts (including Active Server pages 

1 5 and Java Server pages), interpreters, dynamic link libraries, Java classes, and 

complete executable programs. These computer code devices may run on either one 
of, or on a combination of, a client and a server computer. Information on providing 
Web services is provided in the following references which are incorporated herein by 
reference: (1) Visual Studio Core Reference Set, by Microsoft Press, (2) Visual 

20 InterDev 6.0: Web Technologies Reference, by Microsoft Press, (3) Professional 

Active Server Pages 2.0 by Francis et al., published by WROX Press Ltd., (4) Oracle 
PL/SQL Programming by Scott Urman, Published: March 1996, (5) Hitchhikers 
Guide to Visual Basic and SQL Server: with CD-ROM, by William Vaughn, 
Published: May 1997, (6) Using Microsoft SQL Server 6.5 (Special Edition) by 
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Stephen Wynkoop, Published: March 1997, and (7) Advanced PowerBuilder 6 
Techniques by Ramesh Chandak. 

In order to reduce the number of chargeback discrepancies, membership 
records are updated frequently (e.g., once every n days (where n > 1) versus once a 
5 month). Thus, chargeback rejections will result for only those n days versus a month. 
As would be apparent to one of ordinary skill in the art from this disclosure, the 
frequency for updating can be made longer or shorter depending on a balancing 
between system load and increased discrepancies. 

By using the present invention, wholesale customers and manufacturers 
10 submit and resolve chargeback resubmissions online. Denied chargeback requests are 
reconciled by correcting mismatched information, and the requests are resubmitted (if 
appropriate) to the manufacturer. 

As shown in Figure IB, in order to provide this functionality, the present 
invention utilizes an eCommerce Database (DB) populated with chargeback data from 
15 the Chargeback System and from customer entered parameters. Examples of 

applicable databases include any SQL server from Microsoft, Oracle or others, as well 
as non-SQL databases (e.g., relational or object-based databases). Flat files can also 
be used in place of a database, especially where the data in the flat file may be 
presented in a structured format (e.g., XML). 
20 For those customers that have selected to have chargeback reconciliation 

performed electronically, historical chargeback data is made available for viewing 
online. As shown in Figure 2, this includes header information 200 for all chargeback 
claims submitted within a specified period (e.g., the past 6 months). In one 
embodiment, due to the sheer volume of chargeback data, only rejected or partially 
25 rejected line items for claims will be displayed. (Such line items include: (1) detail 
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lines that were not paid, (2) detail lines that were partially paid, and (3) detail lines 
that were fully paid but adjusted from the original submission). The chargeback claim 
history should be searchable by all fields of chargeback information and sorted by 
claim summary fields. The system will store personalized search/sort criteria for 
5 users. As records are viewed, the system will display the manufacturer's status 
assigned by the Chargeback System. 

Disputed information can then be entered or changed on-line using detailed 
line items 205. The customer will have the option of working multiple line 
items/records before submitting a batch of them to the manufacturer. Those 
1 0 changes/updates will be tracked as a part of the normal Chargeback System process. 

Once all information is changed, claims (e.g., formatted as an EDI or XML 
file, or as a flat file) may be resubmitted. This file, extracted from the eCommerce 
database on a scheduled basis, will then be provided as input into Chargeback System 
normal processing. 

1 5 The data flow of the present invention as described above is illustrated in 

simplified form in Figure 3A. Generally, data requests are sent from businesses/ 
customers across a wide area network (e.g., the Internet) using a request transfer 
protocol (e.g., HyperText Transfer Protocol (HTTP), File Transfer Protocol (FTP), or 
Gopher Information Services). Those requests are received by an information server 

20 (e.g., Web server implementing a Web site) configured to listen to the corresponding 
type of request (e.g., HTTP requests). For requests for static information, such as 
general information and forms that are independent of the user, the information server 
can satisfy the request directly. Some other requests, though, require that data be 
retrieved in order to respond to the request. The information server then queries a 

25 database (e.g., an eCommerce database) to provide the necessary information. In one 
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embodiment, the data in the database is updated in real-time, and in an alternate 
embodiment, the data is a snapshot of the actual data. In Figure 3 A, the database is 
loaded with a snapshot of three different information sources (i.e., a chargeback 
history database, a dispute information database, and a chargeback reconciliation 
5 information database) daily. As also seen in Figure 3 A, various components of the 
system may be distributed between several computers, optionally separated by 
firewalls for added security. 

In the embodiment illustrated in Figure 3B, the updating of the database is 
illustrated as occurring at different rates for different activities. Various information 

10 is pushed out of master databases and placed into snapshot databases. The data from 
the snapshot databases is then loaded into an eCommerce database accessible by the 
information server. (In an alternate embodiment, the snapshot database and the 
eCommerce database are merged into a single database that information is imported 
into directly and from which data is extracted for direct transmission to the master 

15 database.) 

As users interact with the information server, it updates data in the 
eCommerce database which eventually must be extracted for transm ;sion back to the 
master databases. Such data is either pulled (as illustrated) or pushed so that it arrives 
to a point that is accessible to the master system(s). The new chargeback data is then 

20 loaded into the chargeback system (e.g., once a day). Similarly, data corresponding to 
orders taken over the WAN (e.g., the Internet or a private medical WAN) are loaded 
into a customer service system periodically (e.g., more frequently than the data is 
loaded into the chargeback system). Data is also extracted from the customer service 
system periodically (e.g., three times a day) in order to update a snapshot of the 

25 products database that can be shipped out from the master system foj importation into 
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the eCommerce database. Similarly, the contracts and reporting systems can export 
data that is also transferred to the eCommerce database. 

In light of the vast amount of data that is likely to be generated in a 
commercial system as described above, filters and/or sorting criteria are provided to 
5 keep the data presented to users to a manageable level. As shown in Figure 4, a 
chargeback history is available, but a filter/sort option is preferable to an unfiltered 
data dump. Nonetheless, using either a filtered or unfiltered interface, at least one 
chargeback in dispute can be selected and revised based on a customer's request. 
Having revised the chargeback claim to correct any discrepancies, the customer 

10 resubmits the chargeback, which is eventually imported into the chargeback system 
(as described above with reference to Figure 3B). 

Figure 5 A illustrates one possible method of filtering/sorting data for easier 
analysis by customers.. Chargebacks can be sorted by fields including, but not limited 
to, all of a customer's distribution centers, select customer distribution centers, and 

15 wholesaler reference identifiers. Also, more specific criteria (e.g., debit memo 

numbers, chargeback numbers, data ranges and selectable filter conditions) further 
specify conditions to be matched to reduce the number of displayed records. As 
would be appreciated by one of ordinary skill in the art, the same filter may be used 
by an account administrator/coordinator to administer chargebacks within the 

20 manufacturer whose goods are sold. Using the interface, the account administrator 
can determine which customers are having trouble with which type of chargebacks. 

Figure 5B illustrates an exemplary use of the search capability described in 
regard to Figure 5A. As shown in Figure 5B, a debit memo number (e.g., 
"01480430") may be entered by the customer as the criteria by which the chargebacks 

25 are to be searched. Figure 6 shows an exemplary display of summary information 
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obtained by the web server searching the eCommerce database based on the criteria 
entered through search request capability described in regard to Figures 5 A and 5B. 
As shown in Figure 6, the results of the exemplary search shown in Figure 5B 
summarizes the claim amount, disputed amount and other parameters that allow a 
5 customer (or account administrator) to quickly understand the nature of the dispute. 
Note that the Debit Memo # corresponds to the debit memo number entered in the 
search request of Figure 5B (i.e., "01480430"). 

By selecting the hyperlink corresponding to the "Debit Memo #" field, the 
customer initiates another data request that obtains detailed line items from the 

10 eCommerce database corresponding to the individual chargeback records for the debit 
memo number selected (e.g., "01480430"). As shown in the summary area 300 of 
Figure 7, the "DM #" field having a value of "01480430" corresponds to nineteen 
disputed transactions. The first three disputed transactions — two for customer 
"BA4894297" and one for customer "AS8240816" -- are initially displayed within 

1 5 the user interface. 

Figure 8 illustrates an alternate embodiment of a user interface according to 
the present invention. In addition to being able to search based on debit memos or 
chargeback details, a user interface according to this embodiment also provides the 
option to look at chargebacks that have been resubmitted. Such a feature enables the 

20 user to track chargebacks that were previously disputed to see if the dispute has been 
resolved. 

In an effort to track and efficiently correct the problems associated with 
particular customers, the present invention optionally also provides a series of pre- 
stored filters that help to identify major problem areas. By ranking problem areas by 
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criteria (e.g., age of claim, contract, distribution center, facility or rejection code), a 
customer may more quickly identify errors in procedure. 

Moreover, a scorecard, such as is shown in Figure 9, provides a summary of 
the results of at least two of the pre-stored filters illustrated in Figure 8. In the 
5 exemplary results, the top 3 variances by contract and top 3 variances by facility 
account for in excess of $349,000 and $248,000, respectively. Perhaps more 
importantly, the top 3 variance by contract account for more than 1,000 lines of 
disputed transactions. By correcting the data entry causing those errors, significant 
work may be avoided. (As would be appreciated by one of ordinary skill in the art, 

10 the types and number of variances can be set by the interface designer or customer in 
order to more closely tailor the error tracking to an individual customer's needs.) 

Rather than require each disputed entry to be updated individually, one 
embodiment of the present invention utilizes a global update tool, as shown in Figure 
10. The Global Update Tool provides a way for users (or administrators) to make 

15 changes to many detail lines at one time. There are two types of "global" changes 
that this tool can be used for: (1) changes to resubmittal values or (2) changes to 
resubmittal status. The flow for changing resubmittal values includes the following 
steps: (1) select a resubmittal field to be changed, (2) enter the value that the 
resubmittal field is to be changed to, (3) provide the selection criteria for the lines to 

20 be changed, and (4) press/select the "Update" button or option. One possible use of 
the global update tool is to add or change a contract code associated with all the 
detailed line items where a contract code changed for a new fiscal year and the user 
forgot to enter the new code. By selecting a date range and the old code, the user can 
update all the incorrect codes across multiple detail lines in a single operation. The 

25 present inventors have recognized that having a global update tool provides 



12 



PU3984US2 

significant advantages. For example, rather than addressing problems one detail line 
at a time, having a global update tool provides a way to globally address a single 
problem that may be affecting multiple detail lines with a single action. 

In one embodiment of the global update tool, the user (or administrator) is 
5 provided the option of reviewing a list of all the line items that will be changed as a 
result of the global update prior to the update so that the user may cancel the update. 
(Also, since multiple users may be updating line items at a time, the present invention 
provides checkpoint and rollback capabilities to prevent multiple writers to the same 
line items.) 

10 As would be further appreciated by one of ordinary skill in the art, various 

security measures will preferably be used to prevent unauthorized use of the system 
and/or data updates. In addition to tracking the validity of each request as it comes in, 
in one embodiment the user interface changes depending on the access rights of the 
user currently using the interface. For example, the interface may present to a less 

15 trusted user the ability to only browse chargebacks while letting a more trusted user 
resubmit chargebacks. 

Moreover, in addition to access control, the present invention is preferably 
augmented with auditing to track who has made each of the submissions, 
resubmissions and queries. Such tracking not only helps to identify which users need 

20 additional training, it also enables the present invention to track if users are reviewing 
transactions that they were not intended to review. 

Obviously, numerous modifications and variations of the present invention are 
possible in light of the above teachings. It is therefore to be understood that, within 
the scope of the appended claims, the invention may be practiced otherwise than as 

25 specifically described herein. 
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